The concept of a graphical user interface (GUI) was introduced in the late 1970s by the Xerox Palo Alto research laboratory. It was added to Apple and Microsoft operating systems to address usability concerns for everyday users that would likely have difficulty navigating the command line. Most casual Windows computer users do not ever need to interact with the operating system via the command line. As the name alludes to, a GUI provides users with an interactive point and click interface for interacting with the operating system and installed applications and services.
The introduction of the GUI opened up widespread appeal and access to computers across many demographics since users would be able to interact with their computer without having to memorize commands or know any programming language. Systems administrators commonly use GUI-based systems for administering Active Directory, configuring IIS, or interacting with databases.
RDP is a proprietary Microsoft protocol which allows a user to connect to a remote system over a network connection and obtain a graphical user interface. The user connects using RDP client software to a target system running RDP server software. RDP uses port 3389 to open a dedicated network channel for sending data back and forth. When connecting via RDP, a user can access the GUI as if they were actually sitting at the computer and logging into it locally. RDP is often used by system administrators to administer remote systems quickly. It can also allow users to access their work computers when traveling or working from home after connecting to a Virtual Private Network (VPN).
Command-line interfaces give users greater control over their systems and can be used to perform a wide variety of day-to-day, administrative, and troubleshooting tasks. It can be leveraged to introduce automation to perform certain tasks quickly (such as adding many users to a domain at once). In Windows operating systems, the main two ways to interact with the system from the command line are via the Command Prompt (CMD) and PowerShell.
The Windows Command Reference from Microsoft is a comprehensive A-Z command reference which includes an overview, usage examples, and command syntax for most Windows commands, and familiarity with it is recommended.
The Command Prompt (cmd.exe) is used to enter and execute commands. A user can enter one-off commands such as ipconfig to view IP address information or perform more advanced tasks such as setting up scheduled tasks or creating scripts and batch files. The Command prompt can be opened from the Start Menu, by typing cmd in the run dialogue box, or by directly launching the binary from C:\Windows\system32\cmd.exe.
After launching cmd.exe we can type help to see a listing of available commands.
For more information on a specific command, type HELP command-name
For more information about a specific command, we can type help "command name".
Enables an administrator to create, delete, query, change, run and end scheduled tasks on a local or remote system.
Parameter List:
Examples:
Note that certain commands have their own help menus, which can be accessed by typing "command" /?. For example, information about the ipconfig command can be seen below.
USAGE:
where - (wildcard characters * and ? allowed, see examples)
Options:
Windows PowerShell is a command shell that was designed by Microsoft to be more geared towards system administrators. PowerShell, like the Windows command line, has an interactive command prompt as well as a powerful scripting environment. PowerShell is built on top of the .NET Framework, which is used for building and running applications on Windows. This makes it a very powerful tool for interfacing directly with the operating system.
Like the command prompt, PowerShell gives us direct access to the file system, and we run the majority of the same commands that we can within a cmd shell.
PowerShell utilizes cmdlets, which are small single-function tools built into the shell. There are more than 100 core cmdlets, and many additional ones have been written, or we can author our own to perform more complex tasks. PowerShell also supports both simple and complex scripts used for system administration tasks, automation, and more.
Cmdlets are in the form of Verb-Noun. For example, the command Get-ChildItem can be used to list our current directory. Cmdlets also take arguments or flags. We can type Get-ChildItem - and hit the tab key to iterate through the arguments. A command such as Get-ChildItem -Recurse will show us the contents of our current working directory and all subdirectories. Another example would be Get-ChildItem -Path C:\Users\Administrator\Documents to get the contents of another directory. Finally, we can combine arguments such as this to list all subdirectories' contents within another directory recursively: Get-ChildItem -Path C:\Users\Administrator\Downloads -Recurse.
Many cmdlets in PowerShell also have aliases. For example, the aliases for the cmdlet Set-Location, to change directories, is either cd or sl. Meanwhile, the aliases for Get-ChildItem are ls and gci. We can view all available aliases by typing Get-Alias.
We can also set up our own aliases with New-Alias and get the alias for any cmdlet with Get-Alias -Name. Interacting with the Windows Operating System
PowerShell has a help system for cmdlets, functions, scripts, and concepts. This is not installed by default, but we can either run the Get-Help "cmdlet-name" -Online command to open the online help for a cmdlet or function in our web browser. We can type Update-Help to download and install help files locally.
TOPIC - Windows PowerShell Help System
SHORT DESCRIPTION - Displays help about Windows PowerShell cmdlets and concepts.
LONG DESCRIPTION
ONLINE HELP -You can find help for Windows PowerShell online in the TechNet Library beginning at http://go.microsoft.com/fwlink/?LinkID=108518.
To open online help for any cmdlet or function, type:
Typing a command such as Get-Help Get-AppPackage will return just the partial help unless the Help files are installed.
NAME - Get-AppxPackage
SYNTAX - Get-AppxPackage [[-Name] "string"] [[-Publisher] "string"] [-AllUsers] [-PackageTypeFilter {None | Main | Framework | Resource | Bundle | Xap | Optional | All}] [-User "string"] [-Volume "AppxVolume"] ["CommonParameters"]
ALIASES - Get-AppPackage
REMARKS - Get-Help cannot find the Help files for this cmdlet on this computer. It is displaying only partial help.
The PowerShell ISE (Integrated Scripting Environment) allows users to write PowerShell scripts on the fly. It also has an autocomplete/lookup function for PowerShell commands. The PowerShell ISE allows us to write and run scripts in the same console, which allows for quick debugging.
We can run PowerShell scripts in a variety of ways. If we know the functions, we can run the script either locally or after loading into memory with a download cradle like the below example.
One common way to work with a script in PowerShell is to import it so that all functions are then available within our current PowerShell console session: Import-Module .\PowerView.ps1. We can then either start a command and cycle through the options or type Get-Module to list all loaded modules and their associated commands.
Sometimes we will find that we are unable to run scripts on a system. This is due to a security feature called the execution policy, which attempts to prevent the execution of malicious scripts. The possible policies are:
Below is an example of the current execution policy for all scopes.
The execution policy is not meant to be a security control that restricts user actions. A user can easily bypass the policy by either typing the script contents directly into the PowerShell window, downloading and invoking the script, or specifying the script as an encoded command. It can also be bypassed by adjusting the execution policy (if the user has the proper rights) or setting the execution policy for the current process scope (which can be done by almost any user as it does not require a configuration change and will only be set for the duration of the user's session).
Below is an example of changing the execution policy for the current process (session).
The execution policy helps protect you from scripts that you do not trust. Changing the execution policy might expose
you to the security risks described in the about_Execution_Policies help topic at
Execution Policy
Do you want to change the execution policy?
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "N"): Y
We can now see that the execution policy has been changed.